Thanks for putting this together! Here are my thoughts:

• We should clarify auth aspects. We are planning an intermediate state where we don't have an SRS yet (which would also have to auth somehow to UCS I guess, especially since the UCS API is public). So for the time being I suggest
  • Creation of context requires data steward role
  • State change to CLOSED and OPEN requires data steward role
  • State change to LOCKED requires an upload context specific access grant or data steward role
  • Obtaining an upload token for the upload context requires an upload context specific access grant or data steward role
• Scrap the part where you get a fixed token when creating the upload context and instead allow dynamic retrieval of tokens per context with configurable lifetimes
• Add a GET:/context/{id} and a GET:/contexts endpoint for inspection of existing contexts, auth again required per-context or data steward

@Cito Can you maybe chip in some thoughts on the auth aspects?

@lkuchenb My thoughts: This is very similar to what we do with the work package service for downloads, and in fact the work package schema already allows a work package type of "upload" which would be pretty much the same as an UploadContext. I think it would be good to align the terminology and methods and use it for both upload and download. The only problem is that currently work packages are based on datasets, but we can always create a complete dataset for the study. We can then also reuse the auth mechanism for work packages, i.e. long-lived work package access tokens and short-lived work order tokens for individual files.

@lkuchenb @Cito following offline discussions, I have made some changes for you to review again